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99-tk-262 92733 
FREEZING OF BUS MASTERS 
5 TITLE OF THE INVENTION 

CIRCUIT FOR MONITORING INFORMATION ON AN INTERCONNECT 

10 FIELD OF THE INVENTION 

The present invention relates to 

information on an interconnect, 

exclusively, the interconnect may 
15 circuit. 

BACKGROUND TO THE PRESENT INVENTION 

Integrated circuits are often provided with debug circuitry which 
20 allows the integrated circuit to be debugged. The integrated 
circuit usually comprises a bus and a plurality of modules 
connected to the bus which put packets onto the bus. The debug 
circuitry is one of these modules. The modules also usually 
include a CPU. In order to operate, the debug circuitry is 
25 arranged to receive information from an external tool, put that 
information onto the bus and to check the response to that 
information or to output the response to the external tool. The 
debug circuitry can also carry out internal checks within the 
integrated circuit . 

30 

However, these known circuits have a problem. If the external 
circuitry identifies that there is a problem with a module, it is 
difficult to identify what has caused the problem in that module. 
This is because the module issuing the information causing the 
35 difficulty will continue to put information onto the bus. This 
means that the information in the module may have significantly 
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changed by the time that the module is looked at. This makes it 
difficult to ascertain why the module in question has caused the 
problem. 



SUMMARY OF THE INVENTION 



It is an aim of embodiments of the present invention to 
address the difficulties of the known arrangements. 

According to one aspect of the present invention, there is 
provided a circuit for monitoring information put onto an 
interconnect by one or more modules, said circuit comprising 
circuitry for determining if the information on the interconnect 
matches one or more conditions; and circuitry for preventing a 
module from putting further information onto said interconnect if 
it is determined that information on the interconnect matches 
said one or more conditions. 

According to a second aspect of the present invention, there is 
provided a method comprising the steps of monitoring information 
on an interconnect, the information being put onto the 
interconnect by one or modules; determining if the information on 
an interconnect satisfies one or more conditions; and preventing 
a module from putting information onto an interconnect if it is 
determined that the information satisfies one or more conditions. 



BRIEF DESCRIPTION OF THE DRAWINGS 



For a better understanding of the present invention and as to how 
the same may be carried into effect, reference will now be made 
by way of example to the accompanying drawings in which: 

Figure 1 shows a block diagram of a processor embodied as an 
integrated circuit connectable to an external memory; 
Figure 2a and 2b show the structure of request and response 
packets put onto the bus of Figure 1; 



Figure 3 shows a block diagram of the relationship of the bus 
analyser, debug module and bus of Figure 1; 

Figure 4 shows a block diagram of the bus analyser of Figure 3; 
Figure 5 shows the interface of the bus analyser of Figure 4 in 
5 more detail; 

Figure 6 shows the watch point comparator of Figure 4 in more 
detail ; 

Figure 7 shows the watch point buffer and watch point buffer 
controller of Figure 4 in more detail; 
10 Figure 8 shows a first controller of Figure 4 in more detail; 
Figure 9 shows a second controller of Figure 4 in more detail; 
and 

Figure 10 shows the debug module of Figure 1 in more detail. 

15 DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS OF THE PRESENT 
INVENTION 

Figure 1 illustrates an integrated circuit or chip 2 according to 
an embodiment of the present invention. On the chip 2, one or 
20 more CPU modules 12 are provided. The or each CPU module 12 has a 
plurality of execution units as well as cache memory and memory 
management units. 
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The chip 2 also has a number of other modules 14 to 20. These 
modules 14 to 20 allow communication to occur with elements 
external to the chip 2. For example, the first module 14 may be 
an external memory interface which allows the chip 2 to interface 
within an external SDRAM. A second module 16 also provides an 
external memory interface with, for example, a flash memory. A 
third module 18 may take the form of a PCI bus interface which 
allows an interface between a bus 2 2 of the chip 2 and an 
external PCI bus. The fourth module may be a timing module 2 0 
which allows timing signals to be output and/or received from 
external devices . 

It should be appreciated that the modules can take any suitable 
form and that the four examples described hereinbefore can be 
replaced by any other suitable modules. The modules which have 



been described have allowed an interface with an external device, 
which is not part of the chip 2 . One or more of the modules may 
not be connected to an external device and may therefore provide 
a function within the chip. More or less than four modules can be 
5 provided. One or more modules may be provided externally of the 
integrated circuit which are able to access the interconnect. 

The chip 2 also includes a debug module 23. The debug module 23 
is connectable to an external debug tool 2 5 which assists in the 
10 . debugging of the chip 2 . 

The debug module 23, the CPU module 12 and the first to fourth 
modules 14 to 20 are all connected to the bus 22. Connected 
between each module and the bus 22 is a respective port 26 . These 

15 ports 26 act as a gateway between the respective module and the 
. bus 22. The ports 26 are each connected to an arbiter 28. The 
arbiter 28 receives information from each of the ports 26. This 
information allows the arbiter 28 to arbitrate between the 
requests and responses and to allow one or more of these requests 

20 and responses to have access to the bus 22 in a given cycle. 

The arbiter 28 can use any suitable method of arbitration. The 
arbitration carried out by the arbiter 28 can take into account 
the one or more characteristics of the request or response. For 
25 example one or more of the following factors can be taken into 
account : 

Is the packet to be put onto the bus a request or a 

• response; 

The type of the request and/or the type of response; 
30 The destination of the request or response; 

The availability of the destination of to receive the 
response and/or process the request; and 

The source of the request or the response. 

• Alternative embodiments of the invention may use none, some or 
35 all of these factors in arbitrating between these requests. 

Additional factors may be taken into account. 

The bus 22 is a split transaction bus which has one or more 



s 



request buses or bus segments and one or more response buses or 
- segments. All of these buses can carry packets at the same time. 
There may be different or the same number of request and response 
segments. However, in alternative embodiments of the present 
5 invention, the bus is not a split transaction bus. 

The structure of the bus messages will now be described with 
reference to Figures 2a and 2b. Figure 2a shows the format of a 
request packet. The request packet has a first field of Fl of 32 

10 bits. The first 8 bits A are used by the bus 22 to identify the 
destination (usually one of the modules) and thus route the 
packet. The remaining 24 bits B, which are sometimes referred to 
as the address, are used by the destination module to identify a 
location within that module or a function of that module. The 

15 second 24 bits B are not used by the bus 22 in order to route the 
packet . 

The request packet also includes an 8 bit source field F2 which 
identifies the source of the request. In other words, information 
20 ■ identifying the module from which the request originates is 
included. This 8 bit address can take the same format as the 8 
bit address A at the head of the packet. This information may be 
used to route a response back to the source of the request. 

25 The packet also has an 8 bit field F3 which identifies the type 
of transaction. In other words, this 8 bit field contains the op- 
code. One of the bits of the op-code field defines the packet as 
being a request packet or a response packet. For other bit 
positions in the op-code field F3 of the request packet, the size 

30 and type of the transaction are defined. For example, the code 
might define the transaction as being a read or a write 
transaction if the request packet is intended for a memory 
interface module or a similar module. 

35 The request packet also includes a transaction identifier field 
F4 which is 8 bits wide. This field is used to identify the 
transaction number. This allows related transactions to be 
processed in the correct order. 




The request packet may also include a data field F5 , which 
contains data for the transaction. Only some types of request 
packets, such as write packets, will contain data. 

5 

The response packet will now be described with reference to 
Figure 2b. The response packet does not have the same address 
field as a request packet but rather has the 8 bit source field 
from the request packet as its address in its first field F6 . 

10 This is used to route the response packet back to the module 
which issued the request. The response packet also has a second 8 
bit field F7 which includes an 8 bit opcode. One of the bits of 
this field will define the transaction as being a response. For 
responses, only one other bit of the opcode is used and this 

15 indicates if the response is a valid response or an error 
response . 

The packet may also include in field F8 n bits of requested data 
for example in the case of a read request being issued by the 
20 requesting module. Not all response packets will include data. 

Finally, the request packet also includes a transaction identity 
field F8 which provides transaction identification information. 
This information may allow related response packets to be sent 
25 consecutively on the bus if required. 

It should be appreciated that the request and response packets 
shown in Figure 2a and 2b may be replaced by any other suitable 
packet structure which may have different fields, additional 
30 fields or only some of the fields shown in the figures. The order 
of the fields in the packets shown in Figures 2a and 2b may be 
different in different embodiments of the present invention. 

Embodiments of the present invention can be implemented in 
35 systems where the requests and responses are not in a packet 
format. A transaction comprises a request and the response to 
that request . 
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The arbiter 28 is arranged to observe the request or response 
packets issued by each of the modules from the respective ports 
26. In one preferred embodiment of the present invention, the 
arbiter will observe the entire request or response packet. 
5 However, in alternative embodiments of the present invention, the 
arbiter may only observe certain fields of the request and 
response packets. In some embodiments of the present invention, 
more than one request and response packet may be presented at a 
given port at the same time. 

10 

In addition to carrying out its normal arbitration functions, the 
arbiter 28 also provides a bus analysing function in conjunction 
with elements of the debug module 23. The bus analysing function 
provides the ability to debug system functions involving bus 

15 transactions. A bus transaction comprises a request and its 
associated response. However, it should be appreciated, that the 
bus analyser can be used other than in a debug context . For 
example, the bus analysing function could be used to detect 
certain events and to generate control signals in response to 

20 those events or to provide detection signals which can be used by 
other elements of the chip or by elements external to the chip. 

The bus analysing function provided by embodiments of the present 
invention allows a transaction or part of transaction (for 
25 example a response or a request packet) satisfying one or more 
criteria to be detected, the capture that transaction if required 
and the prevention of the module issuing the packet satisfying 
the criteria from putting any further packets onto the bus, if 
required . 

30 

Reference is now made to Figure 3 which schematically shows the 
bus 22, a bus analyser 40 and the debug module 23. The bus 
. analysing function is provided by the bus analyser 4 0 which is 
part of the arbiter 28 and the debug module 23 . The elements 
35 defining the bus analysing function may be alternatively provided 
in a separate module, totally in the arbiter 28, totally in the 
debug module 23, or in any other suitable location or locations. 
In preferred embodiments of the present invention, the bus 




analysing function is provided by the arbiter 28 and the debug 
module 23 . This is because the registers and the like can be part 
of the debug module address space . In some embodiments of the 
invention, it may be complex to give the arbiter an address for 
5 the bus analyzer function as this could complicate the 
arbitration performed . 

As can be seen from Figure 3, the bus analyser 40 receives 
request and response signals from the bus 22. These signals, in 
10 preferred embodiments of the present invention are the signals 
which have been allowed onto the bus following arbitration and 
comprise a response or a request packet. 

The bus analyser 40 is connected to the debug module 23 by two 
15 dedicated connections 42 and 44. In other words, the bus analyser 
40 does not use the bus 22 in order to send and receive 
information from the debug module 23 , Each of the two connections 
42 and 44 between the bus analyser 40 and the debug module 23 is 
a two way connection. The information which is transferred via 
20 these connections will be described in more detail hereinafter. 

A block diagram of the analyser is shown in Figure 4 . The 
elements shown in Figure 4 are provided in order to watch for one 
condition or watch point. If more than one condition is to be 

25 . watched for, separate circuitry should be provided for each 
condition. The circuitry shown in Figure 4 can look at the 
response bus and the request bus at the same time. However, if a 
match or hit is detected both from the response and request bus, 
only one of the packets is subject to the further bus analysing 

30 functions. Where the response or request bus comprises more than 
- one segment, only one segment may be considered at the same time. 
In alternative embodiments of the invention, the circuitry is 
able to deal further with both a response packet and a request 
packet if a hit occurs at the same time. This may require the 

35 duplication of at least some of the circuitry. More than one 
segment of the response and/or request bus may alternatively be 
• considered at the same time. 




In alternative embodiments of the present invention which use a 
split transaction bus, only one of the request part of the bus 
and the response part of the bus may be looked at by the 
circuitry at one time. If the request part of the bus and the 
5 response part of the bus are to be looked at the same time, there 
may be at least partial duplication of the circuitry. 

The number of watch points which are monitored at the same time 
as well as the number of bus segments which are monitored at the 

10 same time will depend on the space available on the chip. The 
• more watch points and/or bus segments which are monitored at the 
same time, the more space that is required on the chip 2. It has 
been found that in practice the monitoring of two watch points 
and one response segment and one request segment at the same time 

15 provides useful results without taking up too much space on the 
chip. However other numbers of watch points and/or segments may 
be monitored at the same time. 

The bus analyser 40 does not make any distinction between the 
20 request part of the bus and the response part of the bus . 
However, in alternative embodiments of the present invention, the 
bus analyser may know if a given signal is a request signal or a 
response signal. This may be from the op-code field in the 
respective packets or may be provided in a separate manner. If a 
25 distinction is made between the different types of packets, these 
packets may be processed differently. 

The response and request packets which are on the bus 22 are 
observed by an interface 46. This interface 46 is shown in more 

30 detail in Figure 5. The input signals from the bus 22 are 
buffered in a buffer 100. The clocking in of the signals into and 
out of the buffer 100 is controlled by a clock signal 102. The 
buffer is provided as it may take some time for the signals from 
the bus 22 to be received by the interface block 46. In 

35 particular, in some embodiments of the present invention, the 
signals from the bus may only be received shortly before the next 
rising clock edge. The buffer 100 delays the received response 
and request packets by one clock cycle. As explained 




hereinbefore, the signals observed by the interface 46 are those 
which have been allowed onto the bus. The arbitration function 
• provided by the arbiter 28 will have therefore been previously 
performed on those signals. 

5 

The interface 4 6 is connected to a watch point comparator 4 8 and 
a watch point buffer 52. The watch point comparator will now be 
described with reference to Figure 6 . 

10 The watch point comparator 4 8 receives the stored signals from 
the buffer 100 of the interface 46 from the segments of the bus 
which are currently being monitored. Accordingly, the signals may 
relate to a request and a response. The request signals from the 
interface 4 6 are input to a first comparator 104 and the response 

15 signals are input to a second comparator 106. The first and 
second comparators 104 and 106 receive information from the watch 
point control register 54 . The watch point control register 
provides the comparators with match conditions via input 108. 
Examples of these match conditions will be discussed hereinafter. 

20 

The comparators 104 and 106 compare the request and response 
packets with the match conditions to determine if there is a 
match or hit . 

25 The output of the first and second comparators 104 and 106 are 
connected via outputs 110 and 112 respectively to the watch point 
buffer controller 5 0 (which is shown in Figure 4 and which will 
be discussed in more detail hereinafter) . The output provided by 
the comparators 104 and 106 will indicate whether or not there 

30 has been a match or hit . One or both of the comparators can 
detect a match at the same time. One of the response and request 

packet is given a higher priority. In the event that a match is 
detected at the same time, the one of the request and the 
response having the higher priority is selected and the other of 
35 the request and response is discarded. 

The output 111 of the interface 46 is connected to the watch 
point buffer 52, as mentioned hereinbefore. The watch point 




buffer is illustrated in more detail in Figure 7. The watch point 
buffer 52 comprises a multiplexer 114 and a buffer 118. The 
multiplexer 4 6 receives one input from the interface 4 6 and a 
second input from the output of the buffer 118. The buffer 118 is 
5 controlled by a clock input 120. 

The multiplexer 114 is controlled by a control signal 122 from 
the watch point buffer controller 50. The watch point buffer 
controller 50 controls the multiplexer 114 to select one of the 

10 first and second input signals 111 and 116. When a hit is 
detected, the watch point buffer controller 50 provides a control 
signal which controls the multiplexer 114 to select the input 111 
from the interface 46 to provide the response or request packet 
associated with the hit. This allows the packet or part thereof 

15 associated with the hit to be stored in the buffer 118. The 
buffer 118 is controlled to output the signal received from the 
interface 46 to a first controller 56 via connection 124. 

The connection 124, is, in one embodiment of the present 
20 invention, narrower than the width of the buffer 118. 
Accordingly, the information from the buffer 118 has to be output 
over more than one cycle. When the buffer 118 outputs the packet 
at a first clock cycle, the same information is fed back by the 
second input 116 to the multiplexer 114. Part of the packet is 
25 output to the first controller 56 via connection 124. The 
multiplexer 114 is controlled by the buffer controller 50 to 
select the second input 116. This allows the same packet to be 
written again into the buffer 118 so that it is present in the 
buffer in the next clock cycle. The remainder of the packet can 
30 then be received by the first controller 56. The second input 116 
is not selected if the last part of the packet is being output to 
the first controller 56. The buffer 118 is now emptied of the 
information relating to a given packet. 

35 In alternative embodiments of the present invention, more than 
two cycles may be required to transfer all of the contents of the 
buffer to the first controller. Alternatively, the interconnect 
between the buffer 118 and the controller 56 may be wide enough 




to transfer the contents of the buffer in one cycle. 

The watch point buffer 52 is arranged to capture or store part of 
a request or response packet when a watch point is detected and 
5 the associated action (described in more detail hereinafter) is 
to capture the transaction. All or only part of the request or 
response packet causing the hit can be captured. The part of the 
request or response packet which is captured is referred to as a 
token. In alternative embodiments, the entire transaction, that 
10 is the request and associated response packet, or parts of the 
request and response part of the transaction may be captured. 

In one embodiment of the present invention, the token for 
requests comprises : 
15 Opcode (8 bits) ; 

Destination (first 8 bits of the address) ; 

Address (21 of the bottom 24 bits of the address) ; 

Source identification (8 bits) ; 

Transaction identification (8 bits) ; 
20 Mask (8 bits) ; and 

One 64 bit word of data written, if present. If the request 
had multiple words of data, only the first data word is captured. 
In alternative embodiments of the present invention, all the 
words of data may be captured. 

25 

The captured token for response packets may comprise: 
Opcode (8 bits) ; 

Source of the original request (8 bits) ; 
Transaction identification (8 bits) ; and 
30 One 64 bit word of data read, if present. If the response 

has multiple words of data, only the first word is captured. 

Not all tokens include data. Examples of this include packets 
. which relate to store responses and load responses . 

35 

In alternative embodiments of the invention where only part of a 
packet is captured, different information may be stored. In 
alternative embodiments of the invention, the information to be 




captured may be defined in the action associated with the 
detection of a hit so that different watch points require 
different information to be captured. 

5 The watch point buffer 52 is memory mapped. This means that if 
the action associated with the detection of a hit, the debug 
module is able to directly read the contents of the watch point 
. buffer. This is described in more detail hereinafter. 

10 The watch point buffer controller 50 is, as described 
hereinbef ore, connected to the watch point comparator 4 8 and the 
watch point buffer 52 . The watch point buffer controller is also 
connected to a second controller 58 and the watch point control 
registers 54 . The watch point controller 50 advises the watch 

15 point control registers 54 and the first controller 58 of the 
status of the watch point buffer via connection 126. The buffer 
118 can be empty, full or frozen. If the buffer is frozen, the 
information contained in the buffer is not discarded. 

20 - If no hit is detected, the buffer controller 50 disables the 
multiplexer 114 so that it selects neither the first nor the 
second inputs 111 or 116 and the received packets are effectively 
discarded. This is if the buffer has not previously been frozen. 

25 The watch point buffer controller 50 receives an enable signal 
' via connection 128 from the second controller 58. If the enable 
signal has one value, the buffer controller will enable the watch 
point buffer if required. If the enable signal has the other 
value, the buffer controller 50 will not allow the first or 

30 second input to the multiplexer 114 to be selected so that 
nothing can be stored in the buffer 118. 

The watch point buffer controller 50 advises the second 
controller 58 when a watch point has been detected via connection 
35 130. The second controller 58 provides a control signal to the 
watch point buffer controller 50 via connection 132 to control 
the freezing of the watch point buffer in response to a watch 
* point being detected. As will be discussed hereinafter, certain 




watch points when detected have an associated action which 
requires the buffer 116 to be frozen. The buffer 118 is prevented 
from receiving any new packets when frozen by the buffer 
controller 50 controlling the buffer 118 . The contents of the 
5 buffer 118 are also not discarded. 

Finally, via connection 134, the second controller 58 provides a 
control signal to the watch point buffer controller to control 
the unfreezing of a previously frozen watch point buffer 52 . In 

10 practice, this means that the buffer can receive a new packet. 
The contents of the frozen buffer are effectively discarded. 
These signals will be discussed in more detail hereinafter. It 
should be appreciated that the connection between the watch point 
buffer controller and the second controller 58 can take any 

15 suitable format. 

Reference is now made to Figure 8 which shows the second 

■ controller 58 in more detail. The second controller 58 has a 
state machine 136 which is connected to the watch point buffer 

20 controller 50 via the signals described hereinbefore. The second 
controller 58 also has a word select decoder 138. 

The second controller state machine 13 6 is connected to the watch 

■ point control registers 54 . The control registers 54 supply the 
25 state machine with a watch control register unfreeze buffer 

signal via line 140. This advises the second controller 58 if the 
buffer is frozen. The watch point control registers 54 receive 
from the second controller state machine 13 6 a signal via line 
142 which causes the watch point buffer freeze control to be 
30 ' locked. This signal causes the buffer 52 to be frozen. 

The second controller state machine 13 6 is connected to the debug 
module 123. In particular, the debug module provides the second 
controller state machine 13 6 with the following signals via lines 
35 142 to 152 respectively: 

1. Basic enable signal (142) — This enables the bus analyser 
40 when high to carry out the described functions. When the 
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signal is low, the bus analyser 40 is disabled, 

2. Action interrupt (146) — If an action associated with the 
detection of a hit or match is interrupt , the debug 
module 2 3 sends this control signal to the bus analyser 4 0 

5 to allow this function to be performed. The interrupt 

action is explained in more detail later. 

3. Action trace (148) — If an action associated with the 
detection of a hit or a match is ""trace'', the debug module 
23 sends this control signal to the bus analyser 40 to 

10 allow this function to be performed. The trace action is 

explained in more detail later. 

4. Full but specific hit (150) — This signal is sent if a hit 
has occurred but that the debug module does not have the 
capacity to deal with this hit. Typically, this will occur 

15 if hits occur in successive clock cycles as each hit may 

take two clock cycles or more to be processed. 

5. Grant (152) — This is sent in response to a request signal 
from the state machine and confirms that the request for 
access to the debug module 23 can proceed. This request can 

20 follow a hit. 



The second controller state machine provides the debug module 23 
with the following signals via lines 154 to 160 respectively: 

25 1. Specific hit (154) — This is provided when a specific hit 

occurs. A specific hit is where the precondition and 
match conditions (described hereinafter) have been 
satisfied . 

2. Request (156) — This is the request referred to with 
30 respect to the grant signal on line 152. 

3. Hit (158) — This provided when the match conditions have 

been satisfied, regardless of whether all the 
preconditions have been satisfied. 

4. Packet Loss (160) — this indicates if a packet has been 
35 lost. This will occur if there has previously been a hit 

and the bus analyser 40 is still processing the packet 
associated with that hit. Until the bus analyser 40 has 
finished dealing with the packet associated with the hit. 




the subsequent packets will be lost although it can still 
be determined if those packets cause a hit. 

The word select decoder 13 8 receives a signal from the output of 
5 the watch point buffer 52 via connection 163. The word select 
decoder 13 8 decodes the packet signal and provides data contained 
in the signal to the debug module 23 via connection 162 . The word 
select decoder is required where the width of the interconnect 
between the bus analyzer and the debug module 23 is less than the 

10 size of the buffer. The word select decoder will select which 
bits are to be transferred from the buffer, written to or read 
from registers containing the match information. The word select 
decoder can be omitted if the interconnect between the bus 
analyzer and the debug module is at least as wide as the buffer 

15 and/or the registers. 

Reference will be made to Figure 9 which shows the watch point 
control registers 54 and the first controller 56 in more detail. 

20 The watch point control registers 54 define the match conditions 
the occurrence of which is being monitored. The conditions can be 
as follows: 

Bus transaction type - opcode values and opcode masks allow any 
25 type of response or request packet to be matched. 

Source identity identification - that is the identity of the 
source device of the request or the effective destination for a 
response. This is also maskable. 

30 

Destination device identification - that is the first eight bits 
of the address and is only applicable to the response packets. 
This is maskable. 

35 The remaining 24 bits of the address field are also matchable 
within the start and end of the range defined by this field. In 
other words, anything in this field is matchable. 



It is therefore possible to watch for requests or responses 
intended for a particular destination or from a particular 
source, types of message such as in the case of a response packet 
if it is a normal or an error response, and in the case of a 
5 request packet for a particular type of request packet. It is 
also possible in some embodiments of the present invention to 
look for requests or responses intended for particular functions 
or locations within a module. In other words, it is possible to 
check that all or only some specified bit in a packet match the 
10 defined match conditions. In other words, the match conditions 
may require some or all the bits in a packet to match predefined 
• values . 

A summary of the typical timings now follows: 
15 1. detection of a hit — one clock cycle 

2, detection of a hit and signalling of the hit to the debug 

module — two clock cycles 
3 . detection of a hit and the initiation of the direct 
transfer - two clock cycles 
20 4. transfer of a captured token — three or four clock cycles. 

In preferred embodiments of the present invention, the following 
information is stored: 

preconditions - that is an external precondition, basic 
25 enable or chain latch (this is in the debug module 23); 

match conditions (this is in the watch point registers 54) ; 

actions - this is the action which has to be performed or 
occur when a match condition is detected and the preconditions 
have been satisfied. In other words, the actions define the 
30 ' response to the identification of a given watch point. When it is 
determined that a match or hit has occurred, the action defined 
in the register is carried out. (The actions are generally stored 
in the debug module 23 but the bus analyser will also contain 
some information relating to the actions.) 

35 

The preconditions can include one or more of the following 
conditions : 

Is the bus analyser enabled? If the bus analyser is not 



enabled then the comparator does not carry out a comparison 
operation. 

Has the event counter reached a given count? For example, a 
given condition will only provide a full hit if that condition or 
another condition has occurred a predetermined number of times. A 
hit may have to occur a predetermined number of times before an 
associated action will occur. 

Has a specific chain latch or latch been enabled in the 
debug module 23 . This is representative of a certain condition 
has previously occurred or having first occurred. The condition 
may have occurred anywhere on or off chip. 

The match conditions which are stored in the watch point 
registers 54 can look at one or more of the following conditions 
at the same time. 

Address — this is defined by an address range. 

Source — this is defined by a value, values or range of 
values. A mask can be used. 

Packet destination — this is defined by a value and a mask. 

Transaction opcode — this is defined by a value and a mask. 

The watch point registers 54 have separate destination (the first 
eight bits of the address field) and address (the last 24 bits of 
the address field) fields. The first eight bits are matched 
against a destination value field with a mask if necessary. For 
example if a specific destination is looked for then all eight 
bits must have the specified bits. If a number of destinations 
will satisfy the match requirement then a range of values are 
specified. In practice, this means that some of the values of the 
destination field are not important in determining the match and 
can therefore be masked. The last 24 values of the address can be 
matched against an address range specified by start and end 
register fields. 

Responses do not contain an address and accordingly when the 
opcode field in the watch point control register specifies a 
response, the address and destination field values in the watch 
point control register are ignored by the use of masking. 



As discussed hereinbefore, the response and request packets both 
contain the source identification. The watch points defined in 
the watch point register 54 can thus look for a specific source, 
5 a subset of sources or any source. 

In order for a specific hit to occur, the preconditions and the 
match conditions must both occur. 

10 The actions can be divided into two different categories, a 
general category and a specific category. 

The following actions fall into the general category and are 
stored in the debug module 2 3 : 
15 Reset of all performance counters 318 in the debug module 

23. When a given hit or the nth occurrence of the given hit 
occurs the counters may be reset; 

Increment a performance counter 318 in the debug module 23. 
This may be done if a given hit has to occur n times before a 
20 specific hit occurs; 

Decrement an event counter 316 in the debug module 23; 
Set/clear a chain latch 314; and 

Control the state of the trigger out pin of the chip via 
circuit 320. 

25 

The outputs from the bus analyser are received by a circuit 322 
which in response to the received signal determines which general 
action is required and provides a control signal to one or more 
of the chain latches 314, the event counters 316, the performance 
30 counters 318 and the circuit 320 which has a trigger latch and 
controls the state of the. trigger out pin of the chip. 

The following actions fall into the specific category and are 
stored in the watch point register 54 in the bus analyser 40 or 
35 in the debug module : 

Freeze the source of a packet on detection of a hit (debug 
module 23 ) ; 

Generate a trace message on detection of a hit, using the 




captured token (watch point register 54) ; 

Capture the token and raise a debug interrupt (watch point 
register 54) . 

5 The specific actions will now be described in more detail. One 
action is the capture of a packet in order to enable a trace 
message to be generated. The trace message may be forwarded to 
any module on chip or off chip. For example the trace message can 
be forwarded to the debug module. If a packet is to be captured, 

10 the packet which caused the hit or match is stored in the watch 
point buffer 52 as described hereinbefore. The packet stored in 
the watch point buffer 52 is output to the debug module 23. The 
debug module 23 is shown in Figure 10. This packet is stored in 
the debug module 23 in capture buffer circuitry 300 and in 

15 particular in a trace data latch 302. The elements of the debug 
module 23 can be seen in more detail in Figure 10 . The trace data 
latch is input to a multiplexer 304. The multiplexer 304 also 
receives an input from a further buffer 306 which receives a 
trace bus from a watch point controller of the CPU module 12. The 

20 output of this multiplexer 3 04 is input to a trace message 
• generator 308. This may be provided in conjunction with the 
freeze action. 

In response to the capture of a packet or a part thereof, a trace 
25 message can be generated. This trace message may include 

information on the bus transaction. The trace message can be 
' written to a FIFO 310 or other suitable store in the debug module 

23. In alterative embodiments of the present invention, the FIFO 

or other suitable store may be at any other suitable location on 
30 the chip or off the chip. This trace message is then used to 

assist in the debugging of the chip 2 . In preferred embodiments 

of the present invention, the debug module 23 will determine the 

destination of the trace messages. 

35 An alternative action which is possible is the generation of a 
debug interrupt to a specific CPU or CPUs which will invoke a 
debug handler. The interrupt may be provided to any module on or 
off chip. In this mode, the capture buffer captures the 




associated token and this is read by the debug module 23. In this 
mode, no trace generation is possible. When an interrupt is 
detected, the cause of the interrupt can be determined. The 
interrupt circuit 324 of the debug module 23 reads the captured 
token and uses this information to determine the cause of the 
interrupt. This contrasts with the trace message capture where 
the bus analyser 40 outputs the captured token to the debug 
module. In the interrupt action, the debug module 23 reads the 
captured token in the capture buffer 52. The token is stored in 
the buffer until it is no longer required, that is the buffer is 
frozen. In this mode the debug module 23 will send an interrupt 
signal 326 to the CPU 12. The interrupt circuit 324 and the 
interrupt signal 326 are shown in Figure 10. The debug handler 
will unfreeze the buffer as required. 

Another action which the bus analyser may take is to stop a 
specific bus initiator (that is one of the modules) from making 
any further bus requests or responses. In other words, any of the 
modules which make bus requests or responses can be prevented 
from making any further bus requests or responses. This is 
achieved by controlling the arbiter 28 to not allow requests or 
responses from the module to win access to the bus. This has the 
effect of freezing the module. 

It should be appreciated that in some embodiments of the 
invention, only some types of module can be frozen. For example 
in one embodiment of the invention, it is not possible to freeze 
the CPU module 12. It is also possible to partially freeze a 
module so that it is prevented from putting requests onto the bus 
but can put responses onto the bus or vice versa. 

As described hereinbefore, the capture buffers can also be frozen 
if a hit is detected and the action is to freeze. 

The freezing action of the module may also occur when the watch 
point which is detected causes a debug interrupt in the debug 
module 23 . This can occur at anytime by software by writing to a 
freeze register. 



The freeze action allows the debug module 23 to read any number 
of registers or memory locations after a watch point hit has been 
detected, without the possibility that the values are changed by 
the now frozen module . 

A field is defined which has a number of bits sufficient to 
allocate a different value to each different module. For example 
if the field has 4 bits, up to 16 modules can be provided. In 
preferred embodiments of the invention, there may be no 
correlation between the module number defined by this field and 
its assigned 8 bit address (at the beginning of the address 
field) used to route the packets on the bus. In preferred 
embodiments of the invention, the relationship between the 
address used to route the packets is the module number 
implementation specific and is know by the person who sets up the 
watch points . 

The status of each module, that is whether it is frozen or not is 
stored in the freeze register 312 in the debug module. If a ^1' 
value is stored as the bit of the register for a given module, 
then that module is frozen. Likewise if a "0' value is stored in 
the register, then the module associated with that bit is not 
frozen. The "1' value can of course represent a non frozen state 
and a ^0' value a frozen state in alternative embodiments of the 
present invention. The arbiter 28 will read the values in this 
register and will only allow requests or responses from modules 
which are not frozen to win access to the bus . 

When a watch point action is freeze and there has been a hit, the 
bit of the register associated with the module which caused the 
hit is updated to the freeze value. The debug module 23 or any 
other module such as the CPU or even the external tool connected 
to the debug module is able to read this register. Additionally, 
the debug module 23 can unfreeze a module simply by writing the 
unfrozen value into the bit of the register associated with the 
module. The debug module can also cause a module to be frozen by 
writing the freeze value into the bit of the register associated 




with that module. This may be independent of the bus analyser 40. 
It should be appreciated that in some embodiments of the 
invention, the freeze buffer can be written to in order to change 
the status of a module . In other words a module can be frozen or 
unfrozen simply. This mechanism can be used independently of the 
bus analyzer, in some embodiments of the present invention. 

The register can be accessed by any suitable module on or off 
chip in a nonintrusive manner. 

A similar freeze register 313 is provided for the buffer 52 to 
control whether or not it is frozen. To unfreeze buffer 52 the 
unfreeze value is written into the register. Likewise to freeze 
the buffer 52, the freeze value is written into the registers. 

The precondition and general action registers are in the debug 
module along with the freeze bus master action. The bus analyser 
4 0 knows about the basic enable flags generated by the debug 
module 23, contains the specific match registers and knows about 
some of the actions such as interrupt and trace. 

In alternative embodiments of the present invention, the analyser 
may use the 8 bit source address as the module identity. 

In alternative embodiments of the invention, one or more modules 
other than the source of the packet causing the freezing action 
may be also frozen or may be frozen instead of the source of the 
packet causing the freezing action. In the case of response 
packets, the source of the response packet and/or the source of 
the request packet in response to which the response packet has 
been generated may be frozen. 

In alternative embodiments of the present invention, more than 
one action may be associated with a given watch point. In 
preferred embodiments of the present invention, only one action 
is associated with a given watch point . 



Those values which are maskable may be omitted in the comparison 



carried out by the comparator for certain types of packet. If 
more than one watch point is to monitored at the same time, a 
watch point comparator will be provided for each watch point. 
This may require duplication of some circuitry, although in 
preferred embodiments of the invention, sharing of some or all 
circuitry may be possible. The watch point comparators 104 and 
106 may look for the same or different watch points. 

The first controller 56 has a first controller state machine 55. 
The first controller state machine 55 is connected to the debug 
module 23. The first controller state machine 55 (see Figure 9) 
receives the following signals from the debug module 23 via lines 
170 to 176 respectively: 

1. Request (170) — This for requests from the debug module 
23 . 

2. read/not write (172) — This signal indicates if the 
contents of the watch point registers 54 are to be read or 
written to. 

3. Debug module data (174) — This is for data from the debug 
module being written to control registers or being read 
from control registers. This data allows the values in the 
watch point registers 54 to be changed or allows the 
operation of the first state machine to be changed if 
required . 

4. Debug module valid (176) — This enables the three above 
signals . 

The first controller state machine 55 sends the following signals 
to the debug module 23 via connections 178 to 184 respectively: 

1. Grant (178) — This is issued in response to the request 
received from the debug module. 

2. End of process (180) — This indicates that the watch point 

registers have been updated. 

3. Valid (182) — This signal enables the signals from the 

first controller state machine. 
4. Data (184) — This allows the bus analyser to provide the 




debug module with infoirmation received from a register byte 
select decoder 186. 

The first controller state machine 55 is also connected to a 
5 register byte select decoder 186. The register byte select 
decoder 186 is connected to the watch point control registers 54 . 
The register byte select decoder 186 selects either the watch 
point control registers containing the match conditions or the 
watch point buffer control registers. The decoder also receives 
10 the watch point buffer freeze control signal on line 142, as 
discussed previously. The second controller 58 receives the watch 
point controller unfreeze signal via line 140 from the register 
byte select decoder 186, as discussed previously. The register 
byte decoder is connected to the watch point buffer via 
15 connection 190 and associated control registers from which the 
contents of the buffer can be accessed. 



The register byte select decoder 186 is connected to the first 
controller state machine 55 via connections 194 and 196. These 

20 connections allow data to be written into the register 54 and 
data to be read out of the registers 54 respectively. The 
register byte select decoder 186 receives a register address 
signal from the first controller state machine via line 198 which 
identifies an address in the register for the data to be written 

25 to or for data to be read from. The read not write signal via 
line 200 indicates if a read or a write operation is to take 
place . 

The register byte select decoder 186 is connected to the 
30 registers by a series of inputs and outputs 202. These inputs and 
outputs allow data to be written to or read from the registers 
54 . 

The operation of the bus analyser can be summarised as follows: 
35 packets from the observed part of the bus which have won the 

arbitration are input to the watch point comparators 48; 

the packets are compared with the required match conditions 
stored in the watch point registers 54, assuming that the 




preconditions are satisfied; 

if there is no match the packet is discarded ; 

if there is a match, the action defined in the watch point 
registers 54 will be performed. 

5 

If the action is a capture function, then the token (s) causing 
the hit is captured or stored by the capture buffer. Depending on 
whether an interrupt or a trace is to be performed, the token in 
the buffer is read out to the debug module or is read by the 
10 debug module. 

If the action is to freeze the source module, the freeze register 
is updated and the frozen module is unable to win access to the 
bus 22. 

15 

The bus analyser 4 0 can be used in conjunction with performance 
counters in the debug module to capture selected performance 
parameters to allow the system software, for example contained in 
the debug module to tune the parameters of individual application 
20 specific modules or bus arbiters. For example the number of 
requests, responses, specific accesses to specific modules or 
addresses, errors, cache hits or other performance indicators can 
be determined. 



25 - In preferred embodiments of the present invention, the 
comparators 4 8 and the watch point buffer 52 are provided close 
to the bus, for example with the arbiter. The control registers 
54 and action logic may be located in the debug module. However 
in alternative embodiments of the present invention, the elements 

30 of the bus analyser may be provided at any suitable location, 
together or separately. In one preferred embodiment of the 
present invention, the bus analyser has part of the address space 
allocated to the debug module even where the bus analyser is not 
all provided within the debug module. This means that the arbiter 

35 does not itself require address space. There is however in 
alternative embodiments of the present invention, the bus 
■ analyser may have its own address space or may share address 
space with any other suitable component or module. 



In the preferred embodiment of the present invention, the bus 
analyser observes the requests and responses after arbitration 
has taken place. It should be appreciated that in preferred 
5 • embodiments of the present invention the comparison made by the 
watch point comparators does not delay the normal function of the 
arbiter. In alternative embodiments of the present invention, the 
bus analyser can observe the requests and responses prior to 
arbitration . 

10 

• In the preferred embodiment of the present invention, the bus 
analyser observes requests and responses on a bus. In alternative 
embodiments of the present invention, signals on any other 
suitable type of interconnect may be monitored. In some 
15 embodiments of the present invention, the debug module 23 is 
unaware of the nature of the bus . 



